一、背景

DNS協(xié)議提供了域名與IP地址轉(zhuǎn)換的服務(wù)，是必不可少的網(wǎng)絡(luò)通信協(xié)議之一，也是整個互聯(lián)網(wǎng)運行的基礎(chǔ)。然而，傳統(tǒng)的流量檢測設(shè)備很少對DNS協(xié)議傳輸數(shù)據(jù)的有效性、安全性進行深度分析和檢查。思科在其安全研究報告中形象地稱之為“DNS盲點”。惡意軟件正是利用此機會，通過DNS協(xié)議構(gòu)建隱蔽隧道，進而實現(xiàn)命令控制C&C、數(shù)據(jù)外發(fā)等攻擊。EfficientIP發(fā)布的《全球DNS威脅報告2018》指出，2018年77%的組織至少經(jīng)歷過一次基于DNS的網(wǎng)絡(luò)攻擊，并且DNS隧道占據(jù)了絕大比例。DNS隱秘隧道技術(shù)是MITRE ATT&CK命令與控制矩陣(Command and Control）中的子技術(shù)，其ID為T1071.004。ATT&CK中記錄有30多個目前已知的APT工具使用DNS隧道實施C&C攻擊，比如：OilRig組織使用的Helminth和ISMAgent、OceanLotus使用的Denis等。

當前，針對DNS隧道的檢測方法很多，如基于閾值、統(tǒng)計或?qū)＜乙?guī)則的方法以及基于機器學(xué)習(xí)的方法等。實踐證明，相比其他類方法，基于機器學(xué)習(xí)的DNS隧道檢測方法在檢測效果、防繞過、泛化能力等方面具有較大的優(yōu)勢。

本文將從DNS隧道基礎(chǔ)知識、DNS隧道檢測方法現(xiàn)狀及DNS隧道檢測實踐三個方面介紹相關(guān)內(nèi)容。

二、DNS隧道基礎(chǔ)知識

2.1 DNS隧道簡介

DNS隧道是一種隱蔽隧道，即通過將數(shù)據(jù)或命令封裝到DNS協(xié)議進行數(shù)據(jù)、命令等傳輸?shù)乃淼溃珼NS隧道提供了宿主機與其C&C服務(wù)器之間低速但隱蔽的雙向通信通道。

DNS隧道從用途上可以分為定時隱蔽隧道和存儲隱蔽隧道兩種。前者使用定時屬性將相同結(jié)構(gòu)的DNS請求發(fā)送到C&C，這類消息通常為心跳；而后者則使用DNS協(xié)議封裝編碼的信息，這類信息通常為傳輸?shù)拿舾袛?shù)據(jù)。與定時隱蔽隧道相比，存儲隱蔽隧道可以提供更高的帶寬，因此存儲隱蔽隧道使用更為廣泛。無論哪種隧道類型都使用DNS請求的子域?qū)?shù)據(jù)傳輸?shù)紺&C，并使用這些請求的響應(yīng)從C&C接收數(shù)據(jù)。因此，DNS隧道中傳輸?shù)臄?shù)據(jù)必須遵守DNS協(xié)議規(guī)范，請求的域名必須具有l(wèi)abel，并且必須以字母或數(shù)字開頭和結(jié)尾，每個label的長度不超過63個字符，整個域名的長度不超過255個字符。

2.2 DNS隧道原理

DNS隧道在通信方式上又分為直連和中繼兩種模式。直連是宿主機直接與指定的目標DNS Server(Authoritative NS Server)連接，通過將編碼數(shù)據(jù)封裝在DNS協(xié)議中進行通信。這種方式速度快，但是隱蔽性比較差，很容易被探測到，另外限制比較多，很多場景不允許自己指定DNS Server。而通過DNS迭代查詢實現(xiàn)的中繼隧道則更為隱蔽，但同時因為數(shù)據(jù)包到達目標DNS Server前需要經(jīng)過多個節(jié)點，所以速度上比直連慢。

中繼DNS隧道工作原理如圖1[1]所示，具體如下：

Step1: 攻擊者首先注冊一個域名，如ex.fil，域名指向攻擊者控制的服務(wù)器，并在該服務(wù)器上安裝惡意隧道服務(wù)器端程序。

Step2: 攻擊者利用惡意軟件感染公司內(nèi)網(wǎng)中的主機，之后受感染主機向DNS解析服務(wù)器發(fā)送請求，DNS解析服務(wù)器將請求中繼到根域名服務(wù)器和頂級域服務(wù)器。

Step3: 各級DNS解析服務(wù)器最終將請求路由到被攻擊者控制的安裝了隧道程序的C&C服務(wù)器。

最終宿主機和C&C之間通過DNS解析服務(wù)器建立了連接，并使用該隧道泄露數(shù)據(jù)或?qū)崿F(xiàn)其他惡意目的。由于宿主機和C&C之間沒有直接連接，因此追蹤攻擊者更加困難。

圖 1 DNS隧道原理

2.3 DNS隧道工具

目前有很多開源DNS隧道工具，比如：iodine、DNSCat2、dns2tcp等等，我們稱之為通用DNS隧道工具。這些工具開源并且支持二次開發(fā)，例如基于Iodine開發(fā)的Android DNS隧道工具MagicTunnel，它們支持多種平臺、語言以及記錄類型。

很多APT組織使用的惡意軟件也具有DNS隧道功能，我們稱之為APT工具。相對于通用DNS隧道工具，很多APT工具支持特定的硬編碼命令，其數(shù)據(jù)封裝更精巧，支持的記錄類型更廣泛，檢測也更加困難，比如很多APT工具支持A和AAAA記錄類型。

表 2 具有DNS隧道功能的APT工具

2.4 典型DNS隧道樣例

DNS隧道的使用非常廣泛，除了一些通用的開源DNS隧道工具之外，很多APT工具也使用了DNS隧道技術(shù)。接下來將對部分通用DNS隧道工具和APT工具進行舉例說明。

2.4.1 Iodine

Iodine是基于C語言實現(xiàn)的開源DNS隧道工具。Iodine在默認情況下使用NULL記錄類型，同時可以支持PRIVATE、TXT、SRV、MX、CNAME和A（返回CNAME）類型。Iodine在外發(fā)數(shù)據(jù)時首先會使用GZIP對數(shù)據(jù)進行壓縮然后再編碼發(fā)送，其支持Base32、Base64和Base128編碼。

2.4.2 Dns2tcp

Dns2tcp也是基于C語言實現(xiàn)的開源DNS隧道工具，并且已預(yù)裝在Kali Linux和BlackArch Linux系統(tǒng)。在默認情況下，Dns2tcp使用TXT記錄類型，但它也可以支持KEY記錄類型。在通信時雙向數(shù)據(jù)都使用Base64編碼進行傳輸。

2.4.3 Dnscat2

Dnscat2是基于JAVA實現(xiàn)的開源DNS隧道工具。Dnscat2可以使用TXT、CNAME和MX記錄類型，但是如果僅將數(shù)據(jù)從客戶端發(fā)送到服務(wù)端時它還支持A和AAAA記錄類型。在通信時雙向數(shù)據(jù)均使用十六進制編碼進行傳輸。

2.4.4 ISMAgent

ISMAgent是OilRig組織所使用的具有DNS隧道功能的惡意軟件。通過Wireshark抓包展示ISMAgent發(fā)送初始信標并將數(shù)據(jù)發(fā)送到C&C服務(wù)器的過程。首先木馬使用DNS請求向C&C發(fā)送包含會話ID的初始信標，C&C使用特定的IPv6地址作為響應(yīng)指示隧道建立連接，然后木馬繼續(xù)發(fā)送包含數(shù)據(jù)編號、隨機數(shù)和編碼數(shù)據(jù)的DNS請求，C&C使用特定IPv6響應(yīng)這些請求以指示木馬繼續(xù)發(fā)送數(shù)據(jù)直到所有數(shù)據(jù)都發(fā)送到C&C服務(wù)器，C&C使用包含請求數(shù)的IPv6響應(yīng)以指示數(shù)據(jù)傳輸完畢。

2.4.5 Helminth

Helminth是OilRig組織在攻擊活動中開發(fā)的具有DNS隧道功能的惡意軟件。Helminth有兩種版本，一種是可執(zhí)行可移植的版本，另一種是Power Shell版本，這兩種版本都通過DNS隧道與C&C進行通信。兩個版本的DNS隧道運行方式相同，僅對生成的子域進行更改，使它們看起來不同以逃避檢測。

Helminth PowerShell接收C&C指令的過程如下：首先，Helminth木馬發(fā)出DNS請求啟動與C&C服務(wù)器的會話，C&C用IPv4地址響應(yīng)此信標，木馬從該IPv4中獲得唯一的系統(tǒng)標識符；然后Helminth發(fā)送帶有系統(tǒng)標識的DNS請求，C&C用一個IPv4地址來響應(yīng)該請求，Helminth將IPv4轉(zhuǎn)換為字符作為下載腳本的文件名；最后，Helminth繼續(xù)發(fā)出其他的DNS請求，并將響應(yīng)中的IPv4視為命令寫入腳本文件，C&C以特定IPv4響應(yīng)以指示命令傳輸完畢。

Helminth PowerShell外發(fā)數(shù)據(jù)的過程如下：當收到指示IPv4后，Helminth執(zhí)行腳本同時將執(zhí)行結(jié)果寫入到與腳本同名的文本文件中，最后該文件通過DNS請求發(fā)送到C&C，C&C以固定的IPv4響應(yīng)。

2.4.6 Denis

Denis是Ocean Lotus組織最常用的特種木馬，是一個全功能的后門，攻擊者使用DNS隧道實現(xiàn)了一種更加隱秘的C&C通信方法。為了確保DNS流量不被過濾，攻擊者將后門配置為與Google和OpenDNS 的DNS服務(wù)器通信，因為大多數(shù)組織和安全產(chǎn)品都不會過濾發(fā)送到到這兩個主要DNS服務(wù)器的流量。

Denis首先向Google DNS服務(wù)器發(fā)送包含會話ID的初始信標，并由各級域名服務(wù)器路由到攻擊者控制的C&C服務(wù)器以建立連接，然后C&C以數(shù)據(jù)字節(jié)數(shù)和硬編碼指令響應(yīng)該請求，Denis接收到響應(yīng)后執(zhí)行特定的命令并將命令執(zhí)行結(jié)果通過Google DNS服務(wù)器發(fā)送到C&C。Denis總共支持16條硬編碼指令，大多數(shù)指令涉及與被攻擊計算機文件系統(tǒng)的交互，另外還具有獲取有關(guān)打開窗口的信息、調(diào)用任意API和獲取有關(guān)系統(tǒng)簡要信息的功能。

三、DNS隧道檢測現(xiàn)狀

目前業(yè)界提出了各種DNS隧道檢測方法，總體來說可以分為兩類：一類為基于規(guī)則的檢測方法，一類為基于機器學(xué)習(xí)的檢測方法。

基于規(guī)則的方法是通過閾值來識別DNS隧道，比如監(jiān)控終端請求域名的長度，如果域名長度超過設(shè)定閾值，則會發(fā)出警報。此外，尋找不常用的DNS記錄類型（例如TXT、NULL記錄）是另一種常用的檢測方法[3]?；陂撝档臋z測方法不夠靈活、泛化能力差，并可以通過修改域名長度、請求頻率等特征輕易繞過檢測。

基于機器學(xué)習(xí)的方法通過學(xué)習(xí)歷史數(shù)據(jù)特征，可以準確地識別未知的DNS隱蔽隧道，同時兼具誤報率低、不易被繞過等優(yōu)點?；跈C器學(xué)習(xí)的DNS隧道檢測方法可以總結(jié)為兩類：一類為負載分析，這類方法是受DGA檢測研究的啟示[4]，主要關(guān)注DNS負載的隨機性、字符頻率等特征；另一類為基于時間窗口的流量分析，這類方法關(guān)注DNS請求或響應(yīng)隨著時間變化的統(tǒng)計特征，包括時間窗內(nèi)每個域名的主機名數(shù)量、各種記錄類型（A、AAAA、TXT等）的頻率、子域N-Gram均值和方差、請求和響應(yīng)時間間隔的均值和方差等等。

文獻[5]根據(jù)齊夫定律提出了NgViz方法，該方法使用多條正常DNS流量統(tǒng)計其負載的字符頻率以及字符排名，在推理階段計算輸入的多條DNS請求與正常DNS流量的字符排名和字符頻率的加權(quán)匹配度，通過既定的閾值來判別DNS隧道，但該方法檢測效果不佳。文獻[6]使用DNS請求和響應(yīng)負載的字符熵和長度以及DNS數(shù)據(jù)包包長等特征構(gòu)建隨機森林模型，該實驗表明使用DNS請求和響應(yīng)特征比單獨使用請求或響應(yīng)的特征檢測準確率更高，但是該方法對于未知隧道工具召回率較低，且只能檢測使用TXT、NULL等記錄類型的隧道工具，無法檢測使用A、AAAA記錄類型的新型隧道工具。文獻[7]使用DNS請求的七個特征，包括FQDN中的字符總數(shù)、子域中字符數(shù)、大寫字母和數(shù)字字符的數(shù)量、字符熵以及DNS請求域名的最大標簽長度和平均標簽長度特征構(gòu)建孤立森林模型以檢測DNS隧道。這種方法不涉及任何特定的DNS記錄類型，但由于使用無監(jiān)督的模型，該方法召回率較低。文獻[8]使用DNS請求和響應(yīng)的統(tǒng)計特征，例如：DNS請求和響應(yīng)負載的平均長度、編碼的有效載荷和唯一請求的數(shù)量等，該方案也使用孤立森林算法，但是該方法僅考慮A和AAAA兩種記錄類型，而且在實驗中也僅考慮了Iodine和dns2tcp兩個開源隧道工具。文獻[9]指出，DNS隧道用于在宿主機和C&C交換數(shù)據(jù)時，通常將編碼數(shù)據(jù)封裝到DNS請求和響應(yīng)的負載部分。作者提出了兩種基于機器學(xué)習(xí)的方法：(i)邏輯回歸模型和(ii) k-means聚類，這兩種方法都是從編碼的有效載荷中提取語法特征，例如：字符熵和字符（大寫、小寫、數(shù)字、破折號）數(shù)量，但是該方案也僅僅針對使用TXT記錄的隧道工具dnscat2。文獻[10]分析了幾個開源DNS隧道工具的流量，提取了四種類型的特征：請求和響應(yīng)時間間隔的均值和方差、請求數(shù)據(jù)包大小、域名熵和記錄類型（例如A、TXT、MX等）比例等特征。作者使用了多個DNS隧道工具生成的數(shù)據(jù)訓(xùn)練分類模型，但測試數(shù)據(jù)仍然是由參與訓(xùn)練的隧道工具產(chǎn)生。

四、DNS隧道檢測實踐

現(xiàn)有的基于機器學(xué)習(xí)的DNS隧道檢測方案使用多種DNS隧道工具生成的數(shù)據(jù)訓(xùn)練模型，以使模型可以識別更多的隧道工具，但是這種方案對未參與訓(xùn)練的隧道工具和未知隧道工具的檢測效果不佳，也即模型泛化性能差；另外，在缺少多種隧道工具數(shù)據(jù)的現(xiàn)狀下，一些方案為了提高模型的泛化能力使用統(tǒng)計分析的方法，但這種方案無法實現(xiàn)實時檢測?；趯ι鲜鰞蓚€問題的考慮，本文提出了僅使用DNS請求特征的DNS隧道實時檢測方案，

方案分為四個模塊：第一個模塊為數(shù)據(jù)處理模塊，該模塊主要是解析DNS流量數(shù)據(jù)并提取相關(guān)字段內(nèi)容；第二個模塊為特征提取模塊，該模塊基于數(shù)據(jù)處理模塊的結(jié)果創(chuàng)建并提取DNS隧道檢測相關(guān)的特征；第三個模塊為模型訓(xùn)練模塊，該模塊使用提取的相關(guān)特征訓(xùn)練機器學(xué)習(xí)模型，對模型進行調(diào)優(yōu)并持久化；第四個模塊為模型推理模塊，該模塊加載已經(jīng)訓(xùn)練好的模型并對未知DNS流量進行推理預(yù)測。

4.1 特征創(chuàng)建

DNS隧道通過DNS請求的負載攜帶編碼或加密數(shù)據(jù)，其很多特征的分布均與正常DNS請求有差異，接下來將通過部分特征來分析DNS隧道。

4.1.1 子域長度

正常域名每個label的長度不超過63個字符，整個域名的長度不超過255個字符，正常域名長度往往遠不及255個字符，但DNS隧道為了增加帶寬，其負載往往會攜帶更多的信息。其次由于DNS隧道通常會對數(shù)據(jù)進行編碼，因此其長度比正常域名更長。

4.1.2 最大label長度

與子域長度特征一樣，由于DNS隧道負載攜帶更多的數(shù)據(jù)，因此與正常域名相比其每個label都較長。

4.1.3 字符比例

大寫小寫字母、數(shù)字、特殊字符等在域名中所占的比例也是區(qū)分正?；蛩淼赖闹匾卣鳌Ｒ驗镈NS隧道在傳輸數(shù)據(jù)之前往往使用base32、base64、自定義加密算法等對數(shù)據(jù)進行編碼或加密，因此負載中大寫字母和數(shù)字的比例較高，但正常域名不區(qū)分大小寫，其幾乎不含有大寫字母，且域名中數(shù)字所占比例也較低。

4.1.4 連續(xù)字符比例

由于DNS隧道負載為編碼數(shù)據(jù)，因此其連續(xù)數(shù)字、連續(xù)輔音的比例與正常域名有較大的差異。

4.1.5 熵

編碼的DNS隧道會使用更廣泛的字符，其字符分布的熵值更高。然而正常域名有較高的可讀性，其字符分布與正常英文語料一致，熵值相對較低。因此n-gram熵被視為可以指示DNS隧道活動的重要因素之一。

4.1.6 字符轉(zhuǎn)移概率

基于正常域名可讀性的特征，可以使用正常DNS流量或者英文語料統(tǒng)計N-Gram的轉(zhuǎn)移概率。對于DNS隧道負載，其編碼后的數(shù)據(jù)更隨機，N-Gram轉(zhuǎn)移概率與正常語料差異較大。因此N-Gram轉(zhuǎn)移概率也是區(qū)分正常DNS和隧道的重要特征。

4.2 模型

通過分析各隧道工具生成樣本的特征向量，各隧道工具生成的黑樣本在各特征上均與白樣本存在顯著差異，但不同隧道工具樣本之間也存在顯著差異。因此需要對所使用的特征進行一系列優(yōu)化，否則模型僅能檢測出參與模型訓(xùn)練的隧道工具生成的數(shù)據(jù)，也就是說模型泛化能力差，不能發(fā)現(xiàn)未知隧道工具的數(shù)據(jù)。為了驗證本文所述方法，訓(xùn)練集僅使用一種隧道工具產(chǎn)生的數(shù)據(jù)，通過檢測未參與訓(xùn)練的隧道工具數(shù)據(jù)來測試模型的泛化能力。經(jīng)過調(diào)節(jié)參數(shù)后模型達到最好的檢測效果，模型在驗證集AP 為 100%。

4.3 模型評估

目前的方案對檢測參與訓(xùn)練的隧道工具都具有較高的準確率和召回率，但是對于未參與訓(xùn)練的工具或者未知工具的隧道數(shù)據(jù)檢測效果較差。為了驗證本文所述方案對于參與訓(xùn)練和未知工具隧道數(shù)據(jù)的檢測效果，對多個通用開源DNS隧道工具和APT工具進行單獨測試，最終檢測結(jié)果顯示本方案所述模型可以檢測絕大多數(shù)的通用開源DNS隧道工具和APT隧道工具，而未檢出的樣本均為定時隱蔽隧道數(shù)據(jù)。具體檢測效果如下：

五、 總結(jié)

基于機器學(xué)習(xí)的DNS隧道檢測優(yōu)于傳統(tǒng)基于閾值、統(tǒng)計或?qū)＜乙?guī)則的方法。本文提出的基于機器學(xué)習(xí)的DNS隧道檢測方案優(yōu)于同類方案，僅通過DNS請求的負載部分進行DNS隧道檢測，同時對使用的特征進行了多項優(yōu)化，可以支持多種工具和多種記錄類型。當然，所提出的方案對于檢測定時隱蔽隧道還有局限性，后續(xù)將進一步完善方案以適應(yīng)更多場景。

參考文獻

[1] Nadler A , Aminov A , Shabtai A . Detection of malicious and low throughput data exfiltration over the DNS protocol[J]. Computers & Security, 2019.

[2] Robert Falcone. DNS Tunneling in the Wild: Overview of OilRig’s DNS Tunneling[Online].https://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/,2020.

[3] S. Jaworski. Using splunk to detect dns tunneling[J]. SANS Institute InfoSec Reading Room, 2016.

[4] L. Bilge, E. Kirda, C. Kruegel, and M. Balduzzi. Exposure: Finding malicious domains using passive dns analysis[J]. NDSS,2011.

[5] K.Born, D.Gustafson.NgViz:detecting DNS tunnels through N-gram visualization and quantitative analysis[A]. Proceedings of the Sixth Annual Workshop on Cyber Security and Information Intelligence Research[C]. Oak Ridge, Tennessee, 2010. 1-4.

[6] A. Berg and D. Forsberg, "Identifying DNS-tunneled traffic with predictive models", Jun. 2019, [online] Available: http://arxiv.org/abs/1906.11246.

[7] M. Lyu, H. Habibi Gharakheili, C. Russell. “Mapping an Enterprise Network by Analyzing DNS Traffic,” in Proc. Passive and Active Measurement (PAM), Puerto Varas, Chile, Mar 2019.

[8] A. Nadler, A. Aminov, and A. Shabtai. Detection of malicious and low throughput data exfiltration over the dns protocol. Computers & Security, 80:36–53, 2019.

[9] A. Das, M.-Y. Shen, M. Shashanka, and J. Wang. Detection of exfiltration and tunneling over dns. In Machine Learning and Applications (ICMLA), 2017 16th IEEE International Conference on, pages 737–742. IEEE, 2017.

[10] J. Liu, S. Li, Y. Zhang, J. Xiao, P. Chang, and C. Peng. Detecting dns tunnel through binary-classification based on behavior features. In Trustcom/BigDataSE/ICESS, 2017 IEEE,pages 339–346. IEEE, 2017.

版權(quán)聲明

轉(zhuǎn)載請務(wù)必注明出處

版權(quán)所有，違者必究